Installment configurations within a vehicle and interoperability of devices configured to implement secure communication lockdowns, and methods of use thereof

ABSTRACT

In some embodiments, the present invention provides for a hardware component that includes at least the following: a logic cell; where the logic cell is configured in a static configuration within the hardware component which cannot be changed during run-time; where the hardware component is an intermediary between a processor of an ECU that is located within a vehicle and a communication network of the vehicle; where the logic cell is configured to solely serve a respective communication network; where the logic cell is configured to verify a portion of each communication against at least one of: a pre-defined approved message dictionary, a finite state machine, and an approved communication schema; and performing one of: executing an administrative action with an unauthorized communication or one of: transmitting an approved communication from the hardware component or modifying the approved communication with a pre-defined change.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/983,849, filed May 18, 2018, now U.S. Pat. No. 10,129,259, which is acontinuation of U.S. patent application Ser. No. 15/851,289, filed Dec.21, 2017, now U.S. Pat. No. 10,009,350, which is a divisionalapplication of U.S. patent application Ser. No. 15/486,055, filed Apr.12, 2017, now U.S. Pat. No. 9,866,563, which claims the priority of U.S.Provisional Appln. No. 62/321,372, filed Apr. 12, 2016, each aboveapplication is incorporated herein by reference in its entirety for allpurposes.

FIELD OF THE INVENTION

In some embodiments, the present invention generally relates tospecially programmed computing systems with associated devicesconfigured to implement security communication and configurationlockdowns and methods of use thereof.

BACKGROUND OF THE INVENTION

For example, a vehicle may include a multitude of computers, ElectronicControl Units (ECUs). Typically, ECUs may be interconnected throughvarious networks which may include external communication capabilities,such as Bluetooth™, 3G, Wi-Fi, and others. In some cases, such exemplaryexternal communication capabilities may be utilized to track, controland/or update the vehicle's ECUs and/or operational capabilities.

SUMMARY OF THE INVENTION

In some embodiments, the present invention provides for a hardwarecomponent that includes at least the following: at least one logic cell;where the at least one logic cell is configured in a staticconfiguration within the hardware component which cannot be changedduring run-time; where the hardware component is an intermediarybetween 1) at least one computer processor of an electronic control unit(ECU) that is located within a vehicle and 2) at least one communicationnetwork of the vehicle so that the hardware component receives allelectronic messages transmitted between the at least one communicationnetwork and the ECU; where the at least one logic cell is configured tosolely serve a respective communication network; where the at least onelogic cell is configured to execute at least one verification of eachcommunication associated with the communication network; where the atleast one verification includes: verifying at least one portion of eachcommunication against at least one of: i) at least one pre-definedapproved message dictionary, ii) at least one finite state machine, andiii) at least one approved communication schema; determining, based atleast in part on verifying the at least one portion of eachcommunication, that each communication is: 1) an unauthorizedcommunication or 2) an approved communication; and performing one of: 1)executing at least one administrative action with the unauthorizedcommunication or 2) one of: i) transmitting the approved communicationfrom the hardware component or ii) modifying the approved communicationwith at least one first pre-defined change to generate a changedapproved communication and transmitting the changed approvedcommunication from the hardware component.

In some embodiments, the present invention provides for a method that atleast includes: installing a hardware component in a vehicle; where thehardware component includes at least one logic cell; where the at leastone logic cell is configured in a static configuration within thehardware component which cannot be changed during run-time; where thehardware component is an intermediary between 1) at least one computerprocessor of an electronic control unit (ECU) that is located within thevehicle and 2) at least one communication network of the vehicle so thatthe hardware component receives all electronic messages transmittedbetween the at least one communication network and the ECU; where the atleast one logic cell is configured to solely serve a respectivecommunication network; where the at least one logic cell is configuredto execute at least one verification of each communication associatedwith the communication network; where the at least one verificationincludes: verifying at least one portion of each communication againstat least one of: i) at least one pre-defined approved messagedictionary, ii) at least one finite state machine, and iii) at least oneapproved communication schema; determining, based at least in part onverifying the at least one portion of each communication, that eachcommunication is: 1) an unauthorized communication or 2) an approvedcommunication; and performing one of: 1) executing at least oneadministrative action with the unauthorized communication or 2) one of:i) transmitting the approved communication from the hardware componentor ii) modifying the approved communication with at least one firstpre-defined change to generate a changed approved communication andtransmitting the changed approved communication from the hardwarecomponent.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can be further explained with reference to theattached drawings, wherein like structures are referred to by likenumerals throughout the several views. The drawings shown are notnecessarily to scale, with emphasis instead generally being placed uponillustrating the principles of the present invention. Therefore,specific structural and functional details disclosed herein are not tobe interpreted as limiting, but merely as a representative basis forteaching one skilled in the art to variously employ the presentinvention.

FIGS. 1-29 show some exemplary aspects of the present invention depictedin accordance with at least some principles of at least some embodimentsof the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Among those benefits and improvements that have been disclosed, otherobjects and advantages of this invention can become apparent from thefollowing description taken in conjunction with the accompanyingfigures. Detailed embodiments of the present invention are disclosedherein; however, it is to be understood that the disclosed embodimentsare merely illustrative of the invention that may be embodied in variousforms. In addition, each of the examples given in connection with thevarious embodiments of the present invention is intended to beillustrative, and not restrictive.

For example, while illustrative examples of various embodiments detailedherein are described to be implemented in the automotive industry, suchas in various types of moving vehicles (e.g., cars, tracks, buses,etc.); many other implementations may become apparent to those ofordinary skill in the art; and the principles, methods, systems, anddevices of the present invention can be similarly implemented in variousother environments which utilize computing devices. For instance, theprinciples, methods, systems, and devices of the present invention canbe implemented, with or without any modification(s) that may becomeapparent to those of ordinary skill in the art, in numerous industries,environments, and computing devices such as, but not limited to,aviation, industrial control, computers, medical devices, financialterminals, utilities management, home security, critical infrastructurecomputing systems (e.g., traffic lights, power grids, etc.), and othersimilarly suitable applications.

Throughout the specification, the following terms take the meaningsexplicitly associated herein, unless the context clearly dictatesotherwise. The phrases “in one embodiment” and “in some embodiments” asused herein do not necessarily refer to the same embodiment(s), thoughit may. Furthermore, the phrases “in another embodiment” and “in someother embodiments” as used herein do not necessarily refer to adifferent embodiment, although it may. Thus, as described below, variousembodiments of the invention may be readily combined, without departingfrom the scope or spirit of the invention.

In addition, as used herein, the term “or” is an inclusive “or”operator, and is equivalent to the term “and/or,” unless the contextclearly dictates otherwise. The term “based on” is not exclusive andallows for being based on additional factors not described, unless thecontext clearly dictates otherwise. In addition, throughout thespecification, the meaning of “a,” “an,” and “the” include pluralreferences. The meaning of “in” includes “in” and “on.”

It is understood that at least one aspect/functionality of variousembodiments described herein can be performed in real-time and/ordynamically. As used herein, the term “real-time” is directed to anevent/action that can occur instantaneously or almost instantaneously intime when another event/action has occurred. In some embodiments, theterms “instantaneous,” “instantaneously,” “instantly,” and “in realtime” refer to a condition where a time difference between a first timewhen a search request is transmitted and a second time when a responseto the request is received is no more than 1 second. In someembodiments, the time difference between the request and the response isbetween less than 1 second and several seconds (e.g., 5-10 seconds).

As used herein, the term “dynamic(ly)” means that events and/or actionscan be triggered and/or occur without any human intervention. In someembodiments, events and/or actions in accordance with the presentinvention can be in real-time and/or based on a predeterminedperiodicity of at least one of: nanosecond, several nanoseconds,millisecond, several milliseconds, second, several seconds, minute,several minutes, hourly, several hours, daily, several days, weekly,monthly, etc.

As used herein, the terms “communication” and “message” can be usedinterchnagably and it shall be assumed that the communication cancorresponds to a single message or to a plurality of messages.

As used herein, the term “runtime” corresponds to any behavior that isdynamically determined during an execution of a software application orat least a portion of sofware application.

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securitycommunication lockdown are configured to operate in the distributednetwork environment, communicating over a suitable data communicationnetwork (e.g., the Internet, etc.) and utilizing at least one suitabledata communication protocol (e.g., IPX/SPX, X.25, AX.25, AppleTalk™,TCP/IP (e.g., HTTP), etc.). In some embodiments, the inventive speciallyprogrammed computing systems with associated devices configured toimplement cyber security lockdown are configured to process/track/manageinteractions associated with at least 10 other electronic/computingdevices (e.g., but not limited to, 10-99), at least 100 otherelectronic/computing devices (e.g., but not limited to, 100-999), atleast 1,000 (e.g., but not limited to, 1,000-9,999), at least 10,000other electronic/computing devices (e.g., but not limited to,10,000-99,999), at least 100,000 other electronic/computing devices(e.g., but not limited to, 100,000-999,999), at least 1,000,000 otherelectronic/computing devices (e.g., but not limited to,1,000,000-9,999,999), at least 10,000,000 other electronic/computingdevices (e.g., but not limited to, 10,000,000-99,999,999), at least100,000,000 other electronic/computing devices (e.g., but not limitedto, 100,000,000-999,999,999), at least 1,000,000,000 otherelectronic/computing devices (e.g., but not limited to,1,000,000,000-10,000,000,000).

As used herein, the terms “cyber security lockdown,” “securitycommunication lockdown,” “cyber security communication lockdown,”“configuration lockdown,” and similar identify at least one inventivemethodology of some embodiments of the present invention which is basedon the exemplary principle of locking down an trustful/approvedconfiguration, communication schema, or both; and securing them againstany attempt of cause a change and/or modification. The inventivelockdowns of the present invention are agnostic to cyber-attacks,focusing only on securing at least one approved configuration for allcommunications taking place within a specific set of interconnectednetworks (e.g., all networks in the vehicle, all networks in a powerplant, etc.).

In some embodiments, an exemplary inventive lockdown of a particularcommunication can be implemented on a bit level (e.g., every bit isaccounted for in a message and/or a set of messages) with contextualcommunication awareness (e.g., only specific sequences (e.g., atransmission and/or generation order) and/or rates of communicationmessages are allowed, etc.). In some embodiments, the principles of theinventive lockdowns include maintaining a completely static state of aconfiguration and/or a runtime environment of particular computingdevice(s) so that nothing in the particular computing device(s) wouldchange during the runtime.

Illustrative Non-Limiting Examples of Some Embodiments the PresentInvention Operating in the Automotive Industry

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securitycommunication lockdown are configured to reside within a vehicle whichtypically includes a multitude (e.g., 10, 20, 30, 40, 50, 60, etc.) ofcomputing devices, termed Electronic Control Units (ECUs). An exemplaryECU of an exemplary control system of the vehicle receives the usergenerated signals and/or the signals generated by the sensors and/oractuators, and, responsive to the signals, operates to control a vehiclecomponent involved in performing of a certain function. The exemplaryECU of the exemplary control system may also receive and/or processsignals relevant to performance of the function generated by, and/or bycomponents in, other vehicle control systems. For example, a vehiclethrottle by wire control system that replaces a conventional cablebetween an accelerator pedal and an engine throttle may comprise anelectronic accelerator pedal, an ECU also referred to as an enginecontrol module (ECM), and an electronic throttle valve that controlsairflow into the engine and thereby power that the engine produces. Theelectronic accelerator pedal may generate electronic signals responsiveto positions to which a driver depresses the pedal. The exemplary ECMmay receive the accelerator pedal signals, and in addition electronicsignals that may be generated by other sensors, actuators, andelectronic control systems in the vehicle that provide informationrelevant to the safe and efficient control of the engine via anin-vehicle communication network. The exemplary ECM may then process thedriver input signals and the other relevant signals to generateelectronic control signals that control the throttle. Among the othersensors actuators, and electronic control systems that may providerelevant signals to the ECM over the in-vehicle network are, air-flowsensors, throttle position sensors, fuel injection sensors, engine speedsensors, vehicle speed sensors, brake force and other traction controlsensors comprised in a brake by wire system, and cruise control sensors.

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securitycommunication lockdown are configured to interact with the exemplaryECUs which can be interconnected through various computing networks(e.g., buses) which can involve external communications (e.g.,Bluetooth™, 3G, Wi-Fi, and others) that may be used by the manufacturer,passengers, insurance agencies, and various other 3^(rd) party entitiesfor various purposes such as, but not limited to, track, control, and/orupdate the vehicle remotely. For example, in-vehicle communicationnetworks of modern vehicles are typically required to supportcommunications for a relatively large and increasing number ofelectronic control systems of varying degrees of criticality to the safeand efficient operation of the vehicles. For example, a vehicle mayinclude as many as, but not limited to, seventy or more control systemECUs that communicate with each other and sensors and actuators thatmonitor and control vehicle functions via the in-vehicle network. TheECU's may, by way of example, be used to control in addition to enginethrottle described above, power steering, transmission, antilock braking(ABS), airbag deployment, cruise control, power windows, doors, andmirror adjustment. In addition, an in-vehicle network typically supportson board diagnostic (OBD) systems and communication ports, variousvehicle status warning systems, collision avoidance systems, audio andvisual information and entertainment (infotainment) systems andprocessing of images acquired by on-board camera systems. The in-vehiclenetwork in general also provides access to mobile communicationnetworks, Wi-Fi and Bluetooth communications, radio, TPMS (tire pressuremonitor system) V2X (vehicle to vehicle and vehicle to infrastructurecommunication), keyless entry system, the Internet, and GPS (globalpositioning system).

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securitycommunication lockdown are configured to prevent cyber threats (e.g.,unauthorized access by a 3^(rd) party, injection of a computer virus,etc.). In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securityconfiguration lockdown are configured to maintain the configuration andruntime environment of the various ECUs in the vehicle in the completelystatic state, which is enforced so nothing in them would change duringruntime.

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement securitycommunication lockdown are configured to rely on at least one “approvedmessage dictionary” database and at least one “approved communicationschema” database to execute the security communication lockdown.

In some embodiments, the approved message dictionary database storesdefinitions for all valid messages as pre-defined based onmanufacturer's specification and/or input from another designatedauthority. For example, the approved message dictionary database canstore the “approved” definitions of each message structure and approvedvalue(s) associated with each parameter of each respective message.

In some embodiments, the approved communication schema database storesdefinitions for all communication schemas as defined based onmanufacturer's specification and/or input from another designatedauthority. For example, the approved communication schema database canstore the “approved” definitions of at least one of the following:

-   -   all approved sequences of messages,    -   approved source-destination pairs for specific messages,    -   communication rates (e.g., a periodicity of transmission of each        specific message),    -   messaging logic (protocol) according to the vehicle's internal        state (e.g., engine status, particular speed, lights on, ext.)        and/or external inputs (e.g., rain, slippery road, status of at        least one external system that is connected or seeks to connect        to the vehicle, etc.), and    -   any combinations thereof.

In some embodiments, which utilize inventive state machine(s), theexemplary inventive state machine can be defined to govern whichmessage(s) is/are allowed in a particular state (e.g., the particularcurrent state). For example, the exemplary inventive state machine canbe defined to govern at least one for each particular state:

-   -   all approved sequences of messages,    -   approved source-destination pairs for specific messages,    -   communication rates (e.g., a periodicity of transmission of each        specific message),    -   messaging logic according to the vehicle's internal state (e.g.,        engine status, particular speed, lights on, ext.) and/or        external inputs (e.g., rain, slippery road, status of at least        one external system that is connected or seeks to connect to the        vehicle, etc.), and    -   any combinations thereof.

In some embodiments, the approved message dictionary and approvedcommunication schema, can be represented using a three (3) logical layermodel which may include, but not limited to, for example the followinglogical layers:

-   -   1. Content (data) layer—which represents all approved/valid        (pre-defined) messages contained in the approved message        dictionary;    -   2. Routing layer—which represents all approved        source-destination pairs for specific messages; and    -   3. Context (state) layer—which represents at least one of:    -   all approved sequences of messages,    -   communication rates (e.g., a periodicity of transmission of each        specific message),    -   messaging logic according to the vehicle's internal state (e.g.,        engine status, particular speed, lights on, ext.) and/or        external inputs (e.g., rain, slippery road, status of at least        one external system that is connected or seeks to connect to the        vehicle, etc.), and    -   any combinations thereof.

In some embodiment, all three layers together can be implemented usingthe exemplary inventive state machine as detailed herein.

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securitycommunication lockdown are configured to electronically obtain themanufacture specification and automatically generate the at least oneapproved message dictionary database and/or the at least one approvedcommunication schema database. In some embodiments, the definitionsassociated with the approved message dictionary and the definitionsassociated with the approved communication schemas can reside within thesame database(s).

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securitycommunication lockdown are configured to include exemplary componentsidentified in FIG. 1. For example, in some embodiments, to enforce thesecurity communication lockdown, the exemplary inventive device(s)configured to implement the security communication lockdown can includeone or several ECUs installed inside the vehicle networks so that apredetermined portion of or all communications between various vehiclenetworks flow through the inventive device(s) configured to implementthe security communication lockdown and cannot bypass them. In someembodiments, the exemplary inventive device(s) configured to implementthe security communication lockdown can be configured to control only apart of the vehicle networks which require the security communicationlockdown. In some embodiments, the exemplary inventive device(s)configured to implement the security communication lockdown can beconfigured to control only a single ECU communication to a particularnetwork. In some embodiments, to enforce the security communicationlockdown, the exemplary inventive device(s) is/are configured to betransparent to all other ECUs whose communications can pass throughwithout them requiring any awareness of the inventive device(s)′capabilities and/or functions. For example, other ECUs can continuecommunicating as if it wasn't there.

In some embodiments, to enforce the security communication lockdown in adistributed architecture, as illustrated in FIG. 2, the exemplaryinventive specially programmed computing systems can include numerousinventive devices configured to implement the security communicationlockdown which are positioned such as, but not limited to, that:

-   -   at least one inventive device configured to implement the        security communication lockdown is dedicated to a particular        communication network of the vehicle and acts as the entry/exit        point,    -   at least one inventive device configured to implement the        security communication lockdown is dedicate to each external        communication point (e.g., before a 3G modem, Wi-Fi router,        etc.) (FIG. 2), and/or    -   at least one inventive device configured to implement the        security communication lockdown is dedicated to specific ECUs        within a network(s) (e.g., telematics ECU, infotainment ECU,        engine management ECU).

In some embodiments, to enforce the security communication lockdown in acentralized architecture, as illustrated in FIG. 3, the exemplaryinventive specially programmed computing systems can include a centralinventive device configured to implement the security communicationlockdown which interconnects all of the networks of the vehicle. Forexample, as illustrated in FIG. 3, the exemplary central inventivedevice configured to implement the security communication lockdownnetworks is positioned such that it cannot be bypassed (allcommunication in/out of the network(s), in/out the externalinterface(s), and between the networks shall pass through the exemplarycentral inventive device).

In some embodiments, to enforce the security communication lockdown, theexemplary inventive device(s) is/are configured to verify allcommunications against the approved message dictionary database and/orthe approved communication schema database to ensure it is indeed valid.In some embodiments, as illustrated in FIG. 4, to enforce the securitycommunication lockdown, the exemplary inventive device(s) is/areconfigured to drop (e.g., erase) any communication which has failed thevalidation against the approved message dictionary database and/or theapproved communication schema database for any reason.

In some embodiments, to enforce the security communication lockdown, theexemplary inventive device(s) is/are configured to decide whether toallow a communication to be transferred to its intended destination(s)or to block it and by such prevent an attack.

In some embodiments, to enforce the security communication lockdown, theexemplary inventive device(s) is/are configured to log eachcommunication which is blocked. In some embodiments, to enforce thesecurity communication lockdown, the exemplary inventive device(s)is/are configured to generate an indication (e.g., an alert, a report)to report each failed communication each time or at a predeterminedperiodic basis in batches. In some embodiments, the indication may be invisual form, in audio form, or both.

In some embodiments, to enforce the security communication lockdown, theexemplary inventive device(s) is/are configured to be completelyagnostic to a specific attack or attack strategy, by focusing onenforcing the lockdown on the approved communication(s) (i.e., only thepredefined allowed communications are allow to pass). For example, theillustrative approved message dictionary database and/or theillustrative approved communication schema database are completelystatic and deterministic without any possible modification duringruntime. In some embodiments, the inventive specially programmedcomputing systems with associated devices configured to implement thesecurity communication lockdown are configured to require no updates (aslong as the illustrative approved message dictionary database and/oreach approved message communication schema within the illustrativeapproved communication schema database remain the same) and noconnectivity to any external entity(ies). In some embodiments, theinventive specially programmed computing systems with associated devicesconfigured to implement the security communication lockdown areconfigured to rely on a static decision mechanism according theillustrative approved message dictionary database and/or theillustrative approved message communication schema database.

In some embodiments, the inventive specially programmed computingsystems with associated devices configured to implement the securitycommunication lockdown are configured to provide physical separationbetween all networks that they inter-connect, and thus provide anadditional layer of security against malicious or accidentalunauthorized leak(s) between the networks.

In some embodiments, the inventive devices configured to implement thesecurity communication lockdown are configured to be installed insteadof Gateway ECU(s) which are typically present in the vehicles, and,thus, replace Gateway ECU(s) in form, fit and function, while providingthe described inventive communication lockdown capability.

Illustrative Examples of the Central Inventive Device Configured toImplement the Security Communication Lockdown

In one case, the exemplary central inventive device configured toimplement the security communication lockdown (i.e., the inventive ECU)can interconnect three networks of the vehicle: the Infotainment networkwhich is based on MOST (Media Oriented Systems Transport) protocol, thePowertrain network based on CAN (control area network) protocol andSafety network based on Ethernet and/or FlexRay (ISO 17458-1 to 17458-5)communication protocols. In some embodiments, as illustrated in FIG. 5,the exemplary central inventive device configured to implement thesecurity communication lockdown can include at least the followingcomponents: at least one processor (e.g., micro-processor), a memoryunit (e.g., flash storage memory, DDR RAM based runtime memory), atleast one CAN transceiver, at least one MOST transceiver and at leastone FlexRay transceiver.

In some embodiments, the exemplary micro-processor can have a softwarepackage based on Linux which includes all of the drivers in order tooperate on the specific board (compatible with the processor and memory)and drivers for all three transceivers. For example, in the exemplaryLinux implementation of the exemplary central inventive deviceconfigured to implement the security communication lockdown, there canbe four (4) running processes in parallel: three processes which eachhandle a particular communication on the respective network and a fourthprocessor which runs the inventive security core which implements thesecurity communication lockdown. The exemplary central inventive deviceconfigured to implement the security communication lockdown isconfigured to store the approved message dictionary database, which cancontain the listing of all approved messages in, for example but notlimited to, the XML format, and/or the approved communication schemadatabase. For example, each approved message entry in the database candefine, for example but not limited to, on the bit level (a bit levelrepresentation) all fields that the respective message can have.

In some embodiments, for example, each message can contain a uniquemessage ID. In turn, the approved communication schema database cancontain a definition for a respective communication schema, for examplebut not limited to, in the form of source ECU-target ECU pairs which areapproved to communicate with each other. For example, for each pair, theapproved communication schema database can contain a list of message IDswhich correspond to the approved messages which can be passed betweenthem each respective source ECU-target ECU pair. For example, for eachpair, the approved communication schema database can also define theapproved rate at which each of these messages can be sent (e.g., up to 2times per second). For example, for each pair, the approvedcommunication schema database can also define the approved context orstate(s) of the vehicle, communications, and/or network(s) in which eachmessage can be sent (e.g., defining all combinations of messages whichcan precede the particular message before the particular message isauthorized to be sent).

In some embodiments, as illustrated in FIG. 4, the exemplary centralinventive device configured to implement the security communicationlockdown is configured to handle each received communication, asfollows, but not limited to. The exemplary central inventive deviceconfigured to implement the security communication lockdown isconfigured to receive the message and compare the message against theapproved message dictionary database. If the exemplary central inventivedevice configured to implement the security communication lockdown doesnot match the message to an entry of the allowed messages in theapproved message dictionary database, the exemplary central inventivedevice configured to implement the security communication lockdown isconfigured to block such message. If a match is found, in someembodiments, the exemplary central inventive device configured toimplement the security communication lockdown is configured to log/storethe message's message ID.

In some embodiments, the exemplary central inventive device configuredto implement the security communication lockdown is configured toperform a next check to verify, based, at least in part, on the approvedcommunication schema database, that the source and the destination ECUsand/or networks can communication with each other. If the message passesthis check to for this source-destination pair and message ID, in someembodiments, the exemplary central inventive device configured toimplement the security communication lockdown is configured to furtherperform a next check, by verifying the approved context.

In some embodiments, the exemplary central inventive device configuredto implement the security communication lockdown is configured tocontain in its memory the entire history of messages being passed sincethe exemplary central inventive device was turned on. In someembodiments, the exemplary central inventive device configured toimplement the security communication lockdown is configured to furtherperform the next check, by checking against the history to determinewhether, based on the approved communication schema database, thecontext of the message is approved (e.g., the pre-requisite messageswhich are required for this message to pass were recorded). If any ofthe detailed checks fails, the exemplary central inventive deviceconfigured to implement the security communication lockdown isconfigured to drop the message. If all the detailed checks clear, theexemplary central inventive device configured to implement the securitycommunication lockdown is configured to send the message to its targetnetwork to which the destination ECU is connected.

For example, a tire pressure monitoring sensor (TPMS) which can bewirelessly connected to the Safety network sends a message containingthe pressure of the right front tire to the infotainment computer. Ifthe exemplary central inventive device configured to implement thesecurity communication lockdown determines that this message is a validmessage within the system when the match is found in the approvedmessage dictionary database—i.e., there is an entry which defines thatthere could be a message from TPMS with the pressure of the right fronttire. In addition, the approved communication schema database definesthat the TPMS ECU can send messages to the Infotainment ECU up 1 time asecond and with any context (without any prior history requirements),thus the exemplary central inventive device configured to implement thesecurity communication lockdown verifies the message based on thesedeterminations and passes the message to the infotainment ECU fordisplay to the driver.

If the TPMS sensor is hacked and an attacker tries to send an enginestop message to the Engine ECU in the Powertrain network, the exemplarycentral inventive device configured to implement the securitycommunication lockdown determines that, while the message itself isvalidated since it exists in the approved message dictionary database,the source-destination pair of TPMS ECU and engine ECU does not exist inthe approved communication schema database. For example, the approvedcommunication schema database may define that a particular context and aparticular state of the vehicle do not allow the TPMS sensor to send astop message to the engine. Consequently, the exemplary centralinventive device configured to implement the security communicationlockdown is configured to block (drop/erase) the message, preventing theattack.

In some embodiments, the exemplary central inventive device configuredto implement the security communication lockdown is configured to add apiece of meta-data to the message which indicates that the message hasbeen verified which is recognized by the destination ECU as to thevalidity of the message. In some embodiments, the exemplary centralinventive device configured to implement the security communicationlockdown is configured to alert the source ECU that the message haspassed the verification.

Illustrative Examples of Configuration Lockdown of ECUs

In some embodiments, the inventive specially programmed computingsystems are configured to implement the configuration lockdownprocedures with respect to the inventive devices configured to implementthe security communication lockdown but also implement the configurationlockdown procedures with respect each other ECU resided within thevehicle. For example, the security communication lockdown may beimplemented inside a particular ECU (e.g., adding the inventivesoftware/hardware component to the architecture of the ECU). In anotherexample, the security communication lockdown may be implemented byattaching the inventive software/hardware component to the ECU whichwould implement the inventive communication lockdown between that suchECU and the network.

For example, as illustrated in FIG. 6, in general, the global state ofan ECU at a particular time point/period is defined by the software itsrunning, the state of its memory and/or its hardware components. Forexample, the exemplary inventive configuration lockdown procedure canrely on a definition of software and/or firmware packages (e.g.,drivers) which is/are needed to operate a specific ECU,—i.e., “approvedsoftware package” definition—, which can be set by an authoritativeentity (e.g., a manufacturer). For example, the exemplary inventiveconfiguration lockdown procedure can further rely on an “approved memorymap” definition which can define the contents of the memory whichrequire the lockdown (e.g., the code of the software, configurationparameters, etc.), which at least a part of the memory is writableand/or readable. For example, the exemplary inventive configurationlockdown procedure can further rely on an “approved hardwareconfiguration” definition which at least includes a mapping of allhardware in the specific ECU, including virtual hardware devices (e.g.,hardware devices emulated in software). For example, the approvedhardware configuration definition can include the hardware'sconfiguration parameter(s) (e.g., address, clock, pin setting, operationmodes, and any combination thereof).

In some embodiments, to enforce the configuration lockdown per ECU, anadditional inventive software/firmware and/or hardware component(s)(“the configuration lockdown component(s)”) is/are added to each ECU. Insome embodiments, the type and operating condition(s) of theconfiguration lockdown component(s) may vary based on operational and/orenvironmental factor(s) related to each ECU. For example, in someembodiments, the configuration lockdown component(s) is/are configuredto verify all memory access by each software and/or firmware running onthe ECU and/or by other hardware components. For example, theconfiguration lockdown component(s) is/are configured to perform atleast one of the following, but not limited to:

-   -   1) verify that the approved software package which is stored in        the ECU memory and is loaded once it being executed has not been        modified;    -   2) verify that the approved software package which is loaded        into runtime memory (e.g., RAM) has not changed during the        runtime;    -   3) verify that the approved memory map has not been invalidated        based on the approved memory map definition—e.g., software        and/or hardware entity(ies) is/are using only section(s) of        memory which is/are approved for an operation it/they is/are        trying to do (e.g., read-only section(s) of memory is/are not        being written to, locked section(s) is/are not accessed, code        and instruction memory is not used for data, etc.); and    -   4) verify that the memory which stores the hardware        configuration has not been invalidated based on the approved        hardware configuration definition (e.g., hardware address(es)        is/are not changed, configuration parameter(s) is/are not        changed beyond approved range(s), etc.).

For example, the hardware configuration is usually loaded during theinitialization of the ECU, thus in a typical scenario the hardwareconfiguration should not change at all during the runtime. In someembodiments, to enforce the configuration lockdown per ECU, theinventive configuration lockdown component(s) is/are configured toensure that each hardware component receives only its specificconfiguration and nothing else.

In some embodiments, as illustrated in FIG. 7, to enforce theconfiguration lockdown per ECU, the inventive configuration lockdowncomponent(s) include at least one dedicated hardware component whichphysically separates the memory within the ECU (e.g., both storage andruntime memory) and enforces the approved configuration definition(s)(e.g., the approved software package definition, the approved memory mapdefinition, the approved hardware configuration definition, and anycombination thereof).

As reference herein, the term “storage memory” is directed to anon-volatile computer memory where code and/or data is/are stored atrest (e.g., Hard Drive, Flash memory, etc.).

As reference herein, the term “runtime memory” is directed to anoperational memory used to store code and/or data which is/are used forexecution of a currently running program (e.g., RAM).

In some embodiments, as illustrated in FIG. 8, to enforce theconfiguration lockdown per ECU, the inventive configuration lockdowncomponent(s) include a piece of software or firmware which may mediateall memory access on the ECU. For example, to enforce the configurationlockdown per ECU, the inventive configuration lockdown component(s)is/are configured to reside and/or operate in serial to the memory sothe inventive configuration lockdown component(s) cannot bebypassed—i.e., all required memory accesses shall pass through theinventive configuration lockdown component(s).

In some embodiments, the inventive configuration lockdown component,such the one illustrated in FIG. 7, can include at least one processor(e.g., micro-processor) with built-in non-volatile memory (e.g., aSystem on Chip with the built-in Flash memory). In some embodiments, theinventive configuration lockdown component is connected directly to thestorage memory and/or the runtime memory and all access is through theinventive configuration lockdown component. For example, the processorhas a list in the memory of all memory section(s) which are readableand/or writable in the storage memory and/or the runtime memory. Forexample, the inventive configuration lockdown component is configured tocheck/verify each memory command coming from a main processor of thespecific ECU and/or from another component of the specific ECU. Forexample, the inventive configuration lockdown component is configured tocheck at least one of the following, but not limited to:

-   -   Is the command for read or write?    -   which part of the memory is it trying to access?    -   what address within this memory is it trying to access?

For example, the inventive configuration lockdown component isconfigured to compare those parameters against the approvedconfiguration definition(s) (e.g., the approved software packagedefinition, the approved memory map definition, the approved hardwareconfiguration definition, and any combination thereof) which is/arelocally stored. For example, if the inventive configuration lockdowncomponent determines that the required memory address is listed asaccessible for the particular operation (e.g., read/write), theinventive configuration lockdown component is configured to allow theexecution of such command. For example, if the inventive configurationlockdown component determines that the required memory address is listedas not being accessible for the particular operation, the inventiveconfiguration lockdown component is configured to block the command. Insome embodiments, the inventive configuration lockdown component canreport back to an entity that sent the command that it had an accessviolation. In some embodiments, the inventive configuration lockdowncomponent logs a record of the access violation.

In some embodiments, the present invention provides for an exemplaryinventive device which includes at least the following components: atleast one secure lockdown component that is operationally associatedwith at least one electronic control unit (ECU) of at least one networkincluding; where the at least one secure lockdown component isconfigured such that the device physically separates at least one of: i)the at least one network from any other network, ii) the at least onenetwork from external inputs directed to the at least one network, iii)the at least one ECU from at least one other ECU, iv) the at least oneECU from external inputs directed to the at least one ECU, v) at leastone memory component within the at least one ECU from at least oneprocessing unit within the at least one ECU, and vi) any combinationthereof; where the at least one secure lockdown component includes atleast one processor programmed to execute at least one secure lockdownprocedure and at least one non-volatile memory component, storing atleast one: i) at least one approved message dictionary database,including entries for all valid electronic messages, ii) at least oneapproved communication schema database, including at least one entry forat least one approved communication schema, iii) at least onepre-defined state machine, iv) approved content of at least one memorycomponent within the at least one ECU, and vii) approved configurationof at least one hardware unit within the at least one ECU; where the atleast one processor of the at least one secure lockdown component isconfigured, at runtime, to execute the at least one secure lockdownprocedure that is configured to: analyze each electronic message that isat least one of: i) directed to the at least one network, ii)transmitted within the at least one network, iii) to be externallytransmitted from the at least one network to at least one externalcomputing device, iv) directed to the at least ECU, or v) to betransmitted from the at least one ECU; vi) to be transmitted to the atleast one memory component within the at least one ECU; vii) to betransmitted to configure at least one hardware component within the atleast one ECU; where the at least one secure lockdown component isconfigured to analyze each electronic message based on at least one of:i) the at least one approved message dictionary database, includingentries for all valid electronic messages, ii) the at least one approvedcommunication schema database, including at least one entry for at leastone approved communication schema, and iii) the at least one pre-definedstate machine; identify, based on the analysis of each electronicmessage, at least one unauthorized electronic message that would causeat least one unapproved change to or violate at least one of: i) atleast one operational configuration of the at least one ECU of the atleast one network, ii) at least one communication schema that isutilized by the at least one ECU to communicate with at least one of: 1)the at one other ECU and 2) at least one external electronic computingdevice located outside of the at least one network, iii) the at leastone approved message dictionary database, iv) the at least one approvedcommunication schema database, v) the at least one pre-defined statemachine, vi) the approved content of the at least one memory componentwithin the at least one ECU; vii) the approved configuration of the atleast one hardware unit within the at least one ECU; and block the atleast one unauthorized electronic message from passing through the atleast one secure lockdown component.

In some embodiments, the at least one secure lockdown procedure is atleast one communication secure lockdown procedure.

In some embodiments, the at least one secure lockdown procedure is atleast one configuration secure lockdown procedure.

In some embodiments, the contextual communication awareness analysis isbased, at least in part, on at least one of: at least one pre-determinedcommunication sequence of a plurality of electronic messages and atleast one pre-determined communication rate of the plurality ofelectronic messages.

In some embodiments, the at least one secure lockdown component isconfigured to analyze each electronic message based on at least one of:i) a bit-by-bit analysis and ii) a contextual communication awarenessanalysis.

In some embodiments, at least one operational configuration of the atleast one ECU of the at least one network comprises at least one of: i)at least one approved hardware configuration of the at least one ECU andii) at least one approved software configuration of the at least oneECU.

In some embodiments, the at least one processor of the at least onesecure lockdown component is further configured, at runtime, to verifyat least one of: 1) that the at least one approved softwareconfiguration, stored in the at least one non-volatile memory component,has not been modified; 2) that the at least one approved softwareconfiguration, loaded into a runtime memory, has not changed during theruntime; 3) that an approved memory map has not been invalidated, and 4)that a portion of the at least one non-volatile memory component, whichstores the at least one approved hardware configuration has not beeninvalidated.

In some embodiments, the determination that the at least oneunauthorized electronic message that would cause at least one unapprovedchange to or violate is based, at least in part, on at least one of: apre-determined static state of the operational configuration of the atleast one ECU and a runtime environment of the at least one ECU.

In some embodiments, for each of the all pre-defined valid messages, theat least one approved message dictionary database comprises at least oneentry that defines: at least one approved message structure definitionand at least one approved value of each message parameter.

In some embodiments, for each approved communication schema, the atleast one approved communication schema database comprises at least oneentry that defines at least one of: i) all approved sequences ofelectronic messages, ii) all approved source-destination pairs for eachelectronic message, iii) all approved communication rates, iv) allapproved messaging activity protocols based on an internal state of theat least one network, v) all approved messaging activity protocols basedon at least one external input associated with the at least one network,vi) all approved messaging activity protocols based on an internal stateof the at least one ECU, vii) all approved messaging activity protocolsbased on at least one external input associated with the at least oneECU, and viii) any combination thereof.

In some embodiments, the at least one pre-defined state machine isconfigured to define at least one of: i) all approved sequences ofelectronic messages, ii) all approved source-destination pairs for eachelectronic message, iii) all approved communication rates, iv) allapproved messaging activity protocols based on an internal state of theat least one network, v) all approved messaging activity protocols basedon at least one external input associated with at least one network, vi)all approved messaging activity protocols based on an internal state ofthe at least one ECU, vii) all approved messaging activity protocolsbased on at least one external input associated with the at least oneECU, and viii) any combination thereof.

In some embodiments, the at least one securing lockdown component isconfigured to have at least one of the following logical layers: 1) acontent logical layer that represents all pre-defined valid messages, 2)a routing logical layer that represents all approved source-destinationpairs for each electronic message, and 3) a state logical layer thatrepresents at least one of: i) all approved sequences of electronicmessages, ii) all approved source-destination pairs for each electronicmessage, iii) all approved communication rates, iv) all approvedmessaging activity protocols based on an internal state of the at leastone network, v) all approved messaging activity protocols based on atleast one external input associated with at least one network, vi) allapproved messaging activity protocols based on an internal state of theat least one ECU, vii) all approved messaging activity protocols basedon at least one external input associated with the at least one ECU, andviii) any combination thereof.

In some embodiments, the at least one network resides within a vehicle.

In some embodiments, the at least one ECU is at least one electroniccomputing device configured to perform or affect at least one particularfunction in the vehicle.

In some embodiments, the all pre-defined valid messages are pre-definedbased, at least in part, on a vehicle specification of a vehiclemanufacturer or an ECU specification of the at least one ECU of an ECUmanufacturer.

In some embodiments, the at least one secure lockdown component isfurther configured to: electronically obtain the vehicle specificationfrom at least one trusted electronic source, and dynamically generate,based on the vehicle specification, at least one of: 1) the at least oneapproved message dictionary database, 2) the at least one approvedcommunication schema database, and 3) the at least one pre-defined statemachine.

In some embodiments, the at least one secure lockdown component isfurther configured to erase the at least one unauthorized electronicmessage.

In some embodiments, the at least one unapproved change is a changebased, at least in part, on at least one cyber threat.

In some embodiments, the at least one secure lockdown component isfurther configured to generate at least one indication of the at leastone unauthorized electronic message.

In some embodiments, the at least one secure lockdown component isfurther configured to add a metadata to each approved electronicmessage, wherein the metadata is configured to be recognized by at leastone destination ECU as being approved by the device.

In some embodiments, the at least one network resides outside a vehicle.

In some embodiments, the at least one unauthorized electronic message isrelated to at least one cyber threat.

In some embodiments, the at least one secure lockdown component isconfigured to block the at least one unauthorized electronic message atone of: hardware, at least one location along a software stack, or both.

In some embodiments, the at least one pre-defined state machine isconfigured to implement at least one of: 1) the content logical layer,2) the routing logical layer, and 3) the state logical layer.

In some embodiments, the at least one secure lockdown component isfurther configured to at least one of: log the at least one indicationof the at least one unauthorized electronic message, and transmit the atleast one indication of the at least one unauthorized electronic messageto at least one external electronic destination that is outside thedevice.

In some embodiments, the at least one secure lockdown component isfurther configured to at least one of: generate at least one indicationof at least one authorized electronic message; log the at least oneauthorized electronic message, the at least one indication, or both; andtransmit the at least one indication of the at least one authorizedelectronic message to at least one external electronic destination thatis outside the device.

In some embodiments, the present invention provides for a method that atleast includes incorporating an exemplary inventive device into avehicle, where the exemplary inventive device includes at least thefollowing components: at least one secure lockdown component that isoperationally associated with at least one electronic control unit (ECU)of at least one network; where the at least one ECU resides within thevehicle; where the at least one secure lockdown component is configuredsuch that the device physically separates at least one of: i) the atleast one network from any other network, ii) the at least one networkfrom external inputs directed to the at least one network, iii) the atleast one ECU from at least one other ECU, iv) the at least one ECU fromexternal inputs directed to the at least one ECU, v) at least one memorycomponent within the at least one ECU from at least one processing unitwithin the at least one ECU, and vi) any combination thereof; where theat least one secure lockdown component includes at least one processorprogrammed to execute at least one secure lockdown procedure and atleast one non-volatile memory component, storing at least one: i) atleast one approved message dictionary database, including entries forall valid electronic messages, ii) at least one approved communicationschema database, including at least one entry for at least one approvedcommunication schema, iii) at least one pre-defined state machine, iv)approved content of at least one memory component within the at leastone ECU, and vii) approved configuration of at least one hardware unitwithin the at least one ECU; where the at least one processor of the atleast one secure lockdown component is configured, at runtime, toexecute the at least one secure lockdown procedure that is configuredto: analyze each electronic message that is at least one of: i) directedto the at least one network, ii) transmitted within the at least onenetwork, iii) to be externally transmitted from the at least one networkto at least one external computing device, iv) directed to the at leastECU, or v) to be transmitted from the at least one ECU; vi) to betransmitted to the at least one memory component within the at least oneECU; vii) to be transmitted to configure at least one hardware componentwithin the at least one ECU; where the at least one secure lockdowncomponent is configured to analyze each electronic message based on atleast one of: i) the at least one approved message dictionary database,including entries for all valid electronic messages, ii) the at leastone approved communication schema database, including at least one entryfor at least one approved communication schema, and iii) the at leastone pre-defined state machine; identify, based on the analysis of eachelectronic message, at least one unauthorized electronic message thatwould cause at least one unapproved change to or violate at least oneof: i) at least one operational configuration of the at least one ECU ofthe at least one network, ii) at least one communication schema that isutilized by the at least one ECU to communicate with at least one of: 1)the at one other ECU and 2) at least one external electronic computingdevice located outside of the at least one network, iii) the at leastone approved message dictionary database, iv) the at least one approvedcommunication schema database, v) the at least one pre-defined statemachine, vi) the approved content of the at least one memory componentwithin the at least one ECU; vii) the approved configuration of the atleast one hardware unit within the at least one ECU; and block the atleast one unauthorized electronic message from passing through the atleast one secure lockdown component.

Illustrative Examples of Security Communication Lockdown Based on StaticState Machine—Secured Network Orchestrator (SNO)

In some embodiments, to enforce the security communication lockdown, theexemplary inventive device configured to implement securitycommunication lockdown is configured as a SNO component operating as thestatic (finite) state machine (e.g., a State/Event-based machine, anUnified Modeling Language (UML) state machine, a Specification andDescription Language (SDL) state machine, a Touring machine, having theinput/output tape be in the form of messages going in and out of the SNOcomponent device through the communication interfaces). For example, asdetailed herein, the security communication lockdown can be requiredbased on a security threat of an external origin, an internal origin, orboth. In some embodiments, to enforce the security communicationlockdown, the exemplary inventive SNO component can be a physical ECU ora software component within already existing ECUs to enforce the atleast one approved message dictionary database and/or the at least oneapproved communication schema database. In some embodiments, to enforcethe security communication lockdown, the exemplary inventive SNOcomponent is configured to be secure in itself and resistant to attackswhich can modify its principle of operation. For example, the exemplaryinventive SNO component is configured to include and secure the approvedmessage dictionary database and/or the approved communication schemadatabase, against modification during the runtime, thus upholding thestatic lockdown principles as defined herein. For example, the integrityof the exemplary inventive SNO component is configured to be verifiedand certified using suitable methods and standards such as ISO/IEC15408.

For example, the exemplary inventive SNO component, such as SNO ECU, canat least contain one or more processors (e.g., micro-processors),storage memory, runtime memory and hardware (e.g., hardwaretransceivers) which are typically required to communicate with thenetworks which interconnect through the exemplary inventive SNOcomponent. For example, as illustrated in FIG. 9, the exemplaryinventive SNO component can interconnect an Infotainment network basedon MOST protocol, Powertrain network based on CAN protocol, and/or theSafety network based on FlexRay protocol.

In some embodiments, the exemplary inventive SNO component can be in theform of software component or a combination of software and hardwarecomponents. For example, the exemplary inventive SNO component caninclude a secure separation kernel, such as, but not limited to, as anoperating system kernel, or a middleware between the hardware and theapplications running on top of the hardware. In some embodiments, thesecure separation kernel can be in the form of hardware and/or firmwareand/or software mechanisms whose primary function is to establish,isolate and separate multiple partitions and control information flowbetween the subjects and exported resources allocated to thosepartitions. In some embodiments, the secure separation kernel isimplemented in accordance with the Separation Kernel Protection Profile(SKPP) established by U.S. National Security Agency (NSA) (2007), whosespecific description incorporated herein by reference. For example, thesecure separation kernel of the exemplary inventive SNO component canbe, or a specifically modified version of (modified in accordance withthe principles of the present invention), one or more of the followingseparation kernels, but not limited to, including Green Hills'Integrity™ kernel, Wind River's VxWorks MILS™ kernel, and LynxSoftware's LynxSecure™ kernel.

In some embodiments, the secure separation kernel's functionalities caninclude at least one of the following:

-   -   separation of internal resources used by the Target of        Evaluation Security Functions (TSF) from exported resources made        available to subjects,    -   partitioning and isolation of exported resources,    -   mediation of information flows between partitions and between        exported resources,    -   audit services, and any combination thereof.

In some embodiments, to enforce the security communication lockdown, thesecure separation kernel of the exemplary inventive SNO component isutilized to provide “application partitions,” allowing severalapplications (e.g., processes) to run in their own virtual“compartments,” where each application (e.g., process) can havededicated resource(s) such as, but not limited to, a processor time anda memory allocation. For example, the exemplary inventive SNO componentin the form of the inventive secure separation kernel separates theprocessor(s) and memory resource(s), and/or the use thereof, betweenseveral applications or application partitions (e.g., threads). In someembodiments, the secure separation kernel of the exemplary inventive SNOcomponent can provide the separation between application partitions onat least two levels:

-   -   1. Separation of processor time slots—each application partition        shall have its own statically allocated time slot which will be        enforced by the inventive secure separation kernel (i.e., when        the time slot ends the next partition will be switched in        according to a static scheduler); and    -   2. Separation of memory address space—each application partition        shall have its own memory address space and the inventive secure        separation kernel is configured to enforce that each partition        accesses only its allocated segment (e.g., memory address        range).

In some embodiments, the secure separation kernel utilized in theexemplary inventive SNO component provides a secure isolation betweenapplications or application partitions and thus prevent condition(s)under which they could affect one another (e.g., one infected programcould infect another or one program crashing crashes another). Forexample, since both the processor and memory resources are separated,code from one partition cannot be read or written to the memory of adifferent partition. For example, due to the processor time separation,the secure separation kernel of the exemplary inventive SNO componentcan facilitate a scenario when a first code from one partition can denythe execution of a second code from a different partition since they arescheduled by the inventive secure separation kernel, and thus theoperation of the inventive secure separation kernel prevents a denial ofservice attack by one partition on another. For example, even if amalicious code gets into one partition, the malicious code cannot spreador affect other partitions. In some embodiments, the secure separationkernel of the exemplary inventive SNO component can provide sufficientsecurity protection without going into hardware separation (e.g.,separate processor, memory and other components for a set of applicationpartitions or a set of applications,).

In some embodiments, the secure separation kernel of the exemplaryinventive SNO component is configured to allocate all exported resourcesunder its control into partitions. In some embodiments, the secureseparation kernel of the exemplary inventive SNO component can maintainthe partitions isolated except for explicitly allowed information flows.In some embodiments, the secure separation kernel of the exemplaryinventive SNO component is configured to isolate actions of a subject inone partition from (i.e., cannot be detected by or communicated to)subjects in another partition, unless that flow has been allowed. Insome embodiments, the terms “partition” and “subject” are orthogonalabstractions. For example, the term “partition,” as indicated by itsmathematical genesis, can provide for a set-theoretic grouping of systementities, whereas the term “subject” can be utilized to describe andimplement individual active entities of a system. For example, apartition (a collection, containing zero or more elements) is not asubject (an active element), but may contain zero or more subjects.

In some embodiments, to manage the partitions and the flows, the secureseparation kernel of the exemplary inventive SNO component is configuredto rely, at least in part, on the inventive state machine and/or theapproved message dictionary database, and/or the approved communicationschema database, which are parts of the item designated as “securitycore” in FIG. 10. For example, the secure separation kernel of theexemplary inventive SNO component can be configured to run directly ontop of the hardware (e.g., processor, memory, etc.), and/or to be partof a firmware package (referenced herein as “Board Support Package” or“BSP”) which provides drivers and low level software interface to thevarious hardware components, and/or to run directly on top of the BSP(as illustrated in FIG. 10), between BSP and software interfaces forvarious communication networks/programs.

For example, the secure separation kernel of the exemplary inventive SNOcomponent can be part of or run on top of the Wind River™ board supportpackage (BSP) for the ARM Integrator 920T board which can contain, amongother things, at least the following elements:

-   -   config.h file, which defines constants such as ROM_SIZE and        RAM_HIGH_ADRS    -   Makefile, which defines binary versions of VxWorks ROM images        for programming into flash memory    -   bootrom file, which defines the boot line parameters for the        board    -   target.ref file, which describes board-specific information such        as switch and jumper settings, interrupt levels, and offset bias    -   VxWorks image    -   Various C files, including:        -   flashMem.c—the device driver for the board's flash memory        -   pciIomapShow.c—mapping file for the PCI bus        -   primeCellSio.c—TTY driver        -   sysLib.c—system-dependent routines specific to this board        -   romInit.s—ROM initialization module for the board; contains            entry code for images that start running from ROM.

For example, the inventive modified BSP is configured to perform atleast the following operations:

-   -   Initialize the processor    -   Initialize the bus    -   Initialize the interrupt controller    -   Initialize the clock    -   Initialize the RAM settings    -   Configure the segments    -   Load and run bootloader from flash.

In some embodiments, to enforce the security communication lockdown, thesecure separation kernel of the exemplary inventive SNO component isconfigured as part of a micro kernel which at least includes elementsnecessary to run an application (e.g., memory management routine(s) anda process scheduler). In some embodiments, the exemplary inventive SNOcomponent is configured so that the user can add non-security componentsat the user-space.

In some embodiments, the secure separation kernel of the exemplaryinventive SNO component can allow each communication interface to have aseparate partition which manages its interaction with the exemplaryinventive SNO component configured to enforce the security communicationlockdown. For example, the communication interface can be software(e.g., a daemon [UNIX service] and/or a service) which implements anecessary logic required to send and receive data via the correspondinghardware interface.

In some embodiments, the secure separation kernel of the exemplaryinventive SNO component is configured to contain the necessary functionand drivers to send commands through the operating system to thelow-level firmware BSP which relays it to the hardware. For example, thesecure separation kernel of the exemplary inventive SNO component 1 isconfigured to process messages from software interfaces such as, but notlimited to, UNIX sockets and the UNIX TCP/IP stack, and the low-levelfirmware BSP. For example, the secure separation kernel of the exemplaryinventive SNO component is configured to prevent, for example, 1) aninjection of unauthorized code or data through the UNIX sockets and/orthe UNIX TCP/IP stack to affect/manipulate/change the BSP and/orhardware, and 2) unauthorized data leakage between the UNIX socketsand/or the UNIX TCP/IP stack and an operating system.

In some embodiments, the secure separation kernel of the exemplaryinventive SNO component allows the exemplary inventive SNO component tohandle all communication interfaces in a single partition rather than aseparate partition for each. In some embodiments, the secure separationkernel of the exemplary inventive SNO component is configured to run inat least one dedicated partition.

In some embodiments, in addition to the secure separation kernel, theexemplary inventive SNO component is configured to contain an exemplaryinventive finite state machine, illustrated in FIG. 11, which isconfigured in accordance with the principles of the present inventiondetailed herein to deterministically and statically govern anycommunication passing through.

In some embodiments, as illustrated in FIG. 11, the exemplary inventiveSNO component is also configured to include the approved messagedictionary database and/or the approved communication schema database toenforce the secure communication lockdown and verify each communicationwhich may be configured, but not limited to, as the three logic layermodel described herein. For example, each communication which isreceived is either blocked (dropped) or allowed to continue to itsdestination. For example, the finite state machine of the exemplaryinventive SNO component defines each current context in which aparticular communication is received by the exemplary inventive SNOcomponent (e.g., state of the vehicle/ECUs within vehicle networks). Forexample, the exemplary inventive SNO component is configured to performthe initial verification by comparing the received communication to theapproved message dictionary database and/or the approved communicationschema database for such respective communication. For example, theapproved message dictionary can be stored in at least one local databasewhich contains an entry for every approved message, for example but notlimited to, on the bit level (e.g., the bitwise representation of all ofthe fields of the message with their approved value(s)). For example,the exemplary inventive SNO component is configured to further verifythe communication schema by using the finite state machine and theapproved communication schema database. For example, to verify acommunication schema of the received message against the approvedcommunication schema database, the exemplary inventive SNO componentchecks whether, in the current state of the state machine (which canrepresent the context and/or the current state of all relevant ECUswithin a particular environment (e.g., the vehicle)), the receivedmessage is allowed to be transmitted from the source ECU to the targetECU. If the state dictates that it is allowed, the exemplary inventiveSNO component is configured to complete the verification and send themessage to the target ECU; otherwise, the exemplary inventive SNOcomponent is configured to block (drop) the message, thus preventing anattack.

For example, in some embodiments, the source and destination of themessage are considered to be a part of the message and its context andbe verified by comparing with the approved message dictionary databaseand/or the approved communication schema database in order to verify themessage. For example, as illustrated in FIG. 11, the exemplary inventivestate machine includes any vehicle parameter which governs the set ofapproved messages which can be sent at a given moment (i.e., theexemplary state machine defines the overall state of the vehicle). Forexample, each state vector can contain states of all ECUs or at least aportion of all relevant ECUs within the vehicle at a particularoperational time (e.g., on, idle, open, closed or any other similarlyquantifiable measure(s)). For example, the exemplary inventive statemachine can also contain a pre-configured logic defined by apre-determined authority (e.g., the manufacturer). An example of thepre-configured logic can be: an ECU A is tuned on so ECU B must start anoperation although no communication through a relevant network has beensent because the ECU A has been turned on via a dedicated signal pathwaybetween the ECU A and the ECU B.

For example, as illustrated in FIG. 12, any state within the exemplaryinventive state machine can be represented using at least one statevector. In some embodiments, each state vector can contain all or atleast a relevant portion of vehicle parameters which define thevehicle's state at a given time point and a possible combination ofvalues. For instance, a state vector can include the current speed asreported by the engine ECU, the state of the pedals as reported by theirdedicated ECU and the state of any other relevant additional ECU whichcan be communicated in a quantifiable form.

In some embodiments, for each state (and the state vector which definesit), there is a list defining all valid messages which are approved forit (including their source and destination as part of the message). Insome embodiments, the list is implemented in the form of statetransitions, where each valid message causes as a transition from thecurrent state to another state. For example, in some embodiments, when areceived message is present in the approved message dictionary database,however the exemplary inventive SNO component determines that there isno suitable transition from the current state which corresponds to thereceived message, the exemplary inventive SNO component is configured todrop the message (it is not verified according to the approvedcommunication schema). Accordingly, for such embodiments, the statemachine is configured performs the role of the approved communicationschema database. For example, the approved state machine can be locallystored in memory within at least one database containing an entry foreach state and a list of approved transitions set as described herein.

For example, in some embodiments, each legal message corresponds to astate transition, resulting in numerous states to account for allapproved messages. Consequently, the unverified (illegal) message willnot cause the state transition.

For example, in some embodiments, each stored state contains and/or isassociated with a list of all messages which are allowed for such state.For example, some message(s) of the list of the allowed message cause(s)a state transition.

For example, in some embodiments, the exemplary inventive SNO componentis configured to store the current state in the runtime memory andaccess it when any new communication arrives in order to verify suchcommunication. In some embodiments, once a transition occurs (e.g., thereceived message has been verified and transmitted), the exemplaryinventive SNO component is configured to update the current state. Forexample, FIG. 13 illustrates an example of a communication with a seriesof messages which can be received by the exemplary inventive SNOcomponent, and their verification process utilizing the exemplaryinventive state machine.

In some embodiments, in accordance with the principles of the presentinvention, the exemplary inventive state machine is generated byanalyzing each ECU specification to determine the various states suchECU can be in and which parameters change these states. For example, thefact that the vehicle is moving at all is a state on its own since theengine cannot be turned off while the vehicle is moving. For example,the various parameter(s) of the vehicle which are critical to statetransition(s) (speed, accelerator pedal position, etc.) can also beincluded in each state vector.

In some embodiments, in accordance with the principles of the presentinvention, the exemplary inventive state machine is therefore derivedfrom a plurality of state vectors, where each unique combination of thevarious states in a particular state vector is represented as a singlestate in the machine. For example, in some embodiments, some generalparameters of the vehicle (e.g., speed, etc.) can be disregarded tominimize the amount of states. For example, as detailed above, for eachstate, based on the specification, there can be the list of all theapproved messages from the approved message dictionary which are validin this state.

In FIG. 13, each state in the state machine is illustrated with thecorresponding state vector next to it. As illustrated in FIG. 13, theexample communication(s) received by the exemplary inventive SNOcomponent can indicate that the vehicle being started (i.e., the “start”command sent from an instrument cluster ECU to an engine ECU), theaccelerator pedal being pressed and a message being sent from the pedalECU to the engine ECU, and then the vehicle being turned off by theinstrument cluster ECU. If at some point during the progressions shownin FIG. 13, the exemplary inventive SNO component receives a hand brakemessage from the electronic hand brake ECU when the state of theexemplary inventive state machine identifies that the accelerator pedalis pressed, the exemplary inventive SNO component is configured to blockthe hand brake message (thus blocking an attack) since no transitionexists from the state 4 which corresponds to the hand brake message.

In some embodiments, the exemplary inventive SNO component is configuredto utilize the exemplary inventive state machine, illustrated in FIG.13, as the approved communication schema database, and enforce it. Forexample, every time a communication is received and verified as beingapproved, the exemplary inventive SNO component is configured to updateits state machine to the new state according to the message received.Consequently, a log of updates made to the state of the exemplaryinventive state machine is representative of the history of previouscommunications.

FIG. 14 illustrates an example of an illustrative operation of theexemplary inventive SNO component in a scenario of a convertible vehiclewith the functionality to open and close the roof. For example, due tomechanical reasons, the roof can be opened and closed only below 30miles per hour (mph). In this particular example, the ECUs involved are,for example, the Engine ECU which calculates the current speed and sendsa message the current speed data to other ECUs in the vehicle, theretractable roof ECU which controls the retractable roof operation, theaccelerator pedal ECU which send the command to accelerate, and theinstrument cluster ECU which has all of the controls to start and stopthe engine, and open and close the roof while displaying the currentspeed to the driver. In addition, for this illustrative example, to turnoff the vehicle, the roof must be closed.

In this illustrative example, each ECU has an ID (shown in a large-sizedcircle next to the corresponding ECU) and each message type has an ID(shown in a small-sized circle next to the corresponding message). Inthis illustrative example, as illustrated in FIG. 15, an exemplaryapproved communication protocol/schema is defined to consist of fourfields for each message: Source ECU, Destination ECU, Message ID andvalue which is sent. Each field is 8 bits long. For this illustrativeexample, the source and destination ECU values are 1-4; the message IDvalues are 1-5.

For this illustrative example, an approved authority (e.g.,manufacturer) can provide the following specification for relevant ECUs.The engine ECU updates the instrument cluster and the retractable roofECU with the current speed which is defined in the range of 0-250 mph.The retractable roof ECU updates the instrument cluster with the currentstate of the roof (0=closed, 1=open). The accelerator pedal ECU updatesthe engine ECU with the current position of the pedal defined by acontinuous value between 0-1 which 1 is fully depressed and 0 is notdepressed at all. The instrument cluster ECU sends engine start/stopcommands and roof open/close commands to the engine and retractable roofECUs respectively. In this example, the above exemplary specification istranslated into the approved message dictionary, depicted in FIG. 16,which is then stored in at least one database which is stored within theexemplary inventive SNO component and/or accessed by the exemplaryinventive SNO component.

As shown in FIG. 16, the exemplary “engine start” command is definedwith value 1 and the exemplary “engine stop” with value 0; respectively,the exemplary “roof open” command is defined with value 1 and theexemplary “roof close” command is defined with value 0. For thisspecific example, each state vector for the exemplary finite statemachine of this example is generated by deriving all relevant stateswhich the various ECUs can be in (the conditions under which their modeof operation changes according to the specification). FIG. 17 shows anillustrative state vector for this specific example.

For example, the retractable top ECU changes state when the speed goesabove 30 mph and when it goes below 30 mph from above 30 mph. Thus, thestate vector will contain a state which tells is whether the vehicle isat a speed where the roof can be operated (a “slow speed” state) or not(a “fast speed” state). FIG. 18 illustrates a schematic representationof the exemplary inventive state machine adopted for this specificexample. FIG. 18 illustrates that each state has a corresponding statevector. For example, an exemplary state transition is done when at leastone specific message with a specific value is received by the exemplaryinventive SNO component. The exemplary inventive SNO component theupdates the respective state vector with each validated message (even ifa state change did not occur, e.g. speed went up from 20 to 22 mph).

In addition to enforcing the messages being sent in context, theexemplary inventive SNO component utilizing the state machine can alsoenforce (prevent) illegal value changes which are attempted withoutstate transitions. For instance, the authority (e.g., manufacturer) maydecide that the speed value can be updated only when the change is morethan 5 mph, when the exemplary inventive SNO component receives amessage which carries a new speed value, the exemplary inventive SNOcomponent analyzes the message based on the exemplary state machine todetermine if the new speed value differs from the current speed value inthe current state vector by more than 5 mph. If the new speed value doesnot differ by more than 5 mph, the exemplary inventive SNO component isconfigured to discard the message. Thus, the exemplary inventive SNOcomponent safeguards the integrity of the current state using the statevector.

Table 1 show an exemplary code which is executed by the exemplaryinventive SNO component when the exemplary inventive SNO componentreceives a message received while the exemplary state machine is in the“Engine On Roof Closed” state, identified in FIG. 18.

In some embodiments, the inventive specially programmed computingsystems can include a separate finite state machine configured for eachpair of ECUs who communicate with each other, resulting in a network ofspecialized state machines. In some embodiments, the inventive speciallyprogrammed computing systems can include a separate finite state machineconfigured for each pair of communication networks are jointly utilizedto exchange messages between various ECUs. In some embodiments, theinventive specially programmed computing systems can include a separatefinite state machine for each process in the vehicle can be used. Forexample, in the above example with the retractable roof, a separatefinite state machine is defined for the operation of the retractableroof. In such case, the exemplary inventive SNO component(s) can beconfigured to update states of several state machine for each messagereceived.

In some embodiments, the inventive specially programmed computingsystems can include an automatic tool which electronically acquires, forexample, a manufacturer specification and generates a particularapproved message dictionary, each specific state vector and acorresponding state machine. For example, the automatic tool can acquirethe specification which is encoded in a tagged language (such as WL).

In some embodiments, the inventive specially programmed computingsystems and associated inventive devices configured to enforce thesecurity communication lockdown are fully deterministic, can be fullyanalyzed using a computer program and easily certified for safety andsecurity. For example, an exemplary analysis can verify that under eachparticular input a particular inventive state machine will not enter anundefined state and/or unauthorized state and that the particularinventive state machine and a corresponding inventive SNO component(s)behave according to predefined specifications.

In some embodiments, the inventive specially programmed computingsystems and associated inventive devices configured to enforce thesecurity communication lockdown can include a partial state machinewhich covers only a portion of all possible states of the vehicle whichcan be defined based on the manufacturer's specification, and eachcommunication which doesn't match any state is either dropped or allowedby the lockdown device, as long as each message related to thecommunication can be verified against the approved message dictionarydatabase.

TABLE 1 BOOL CheckMessage_EngineOnRoofClosed(Message m) {if(CheckMessageInApprovedDictionary(m) != TRUE) // Check message appearsin approved message dictionary | return FALSE; | if(m.MessageID == 2 &&m.SourceECU == 2) { | UpdateStateVector(m); // Update the state vectorwith the current state | return MessageSend(INSTRUMENT_CLUSTER_ECU, m);// If message contains roof status send it to the instrument cluster fordisplay } if(m.MessageID == 3 && m.SourceECU == 3) { |UpdateStateVector(m); // Update the state vector with the current state| return MessageSend (ENGINE_ECU, m); // If message contains updatedaccelerator pedal position, send it to engine ECU } if(m.MessageID == 4&& m.SourceECU == 4) // Engine start/stop message { | if (m.Value == 0)| { | | if(MessageSend(ENGINE_ECU, m) == TRUE); // If message containsstop command send it to engine ECU | | { | | | CurrentStatus =ENGINE_OFF; // If message sent successfully to engine move state toEngine Off | | | UpdateStateVector(m); // Update the state vector withthe current state | | | return TRUE; | | } | | else | | | return FALSE;// Operation not completed successfully | } | else | | return FALSE; //Engine already started } if(m.MessageID == 5 && m.SourceECU == 4) //Roof open/close message { | if (m.Value == 1) | { | |if(MessageSend(RETRACTABLE_ROOF_ECU, m) == TRUE); // If message containsopen command send it to retractable roof ECU | | { | | | CurrentStatus =ENGINE_ON_ROOF_OPEN; // If message sent successfully move state to openroof state | | | UpdateStateVector(m); // Update the state vector withthe current state | | | return TRUE; | | } | | else | | | return FALSE;// Operation not completed successfully | } | else | | return FALSE; //Roof already closed } return False }

In some embodiments, the inventive specially programmed computingsystems and associated inventive devices configured to enforce thesecurity communication lockdown (the inventive lockdown devices) arefurther configured to also implement protocol translation capabilitieswhere they can serve as the data interpreter between the communicationnetworks connected to them. For example, after a message is validated,the inventive lockdown devices can be configured to translate themessage based on a communication protocol of a receiving network and/orECU. For example, if the message is valid, the inventive lockdowndevices can translate a particular message from the MOST protocol to theCAN protocol.

In some embodiments, the inventive lockdown devices can be configured tohold a secure memory which store at least one cryptography key ofsuitable kind and/or other similar security related data such assecurity certificates. In some embodiments, the inventive speciallyprogrammed computing systems can be configured to utilize cryptographykeys and/or certificates for internal and/or external ECU communicationsor any other suitable purpose such as, but not limited to, vehicleidentification for online payments, authentication and encryption forvehicle to vehicle communication, authentication of updates receivedfrom the manufacturer, effectively serving as a Trusted Platform Module(TPM) for other ECUs.

In some embodiments, the inventive lockdown devices can be configured toemploy encryption and/or authentication scheme(s) at either networklevel and/or individually ECU level, thus allowing for terminatingencrypted communication and starting another one to the destination orany other combination of session encryption and authentication networksconnected to it.

For example, in some embodiments, an exemplary inventive lockdowndevice, which is connected to an automotive infotainment MOST networkand a critical safety LIN network, can be configured, based on, themanufacturer's request to deny all communications between the MOSTnetwork and the safety LIN network by even though both networks belongto the same vehicle. In another example, the exemplary inventivelockdown device can be configured to allow telemetry data, specified bythe manufacturer, that is generated at a specific ECU connected to anengine management CAN network to be communicated into the MOST networkin order for it to display that data graphically on the infotainmentscreen.

In another example, the inventive lockdown devices can be configured toprotect a privacy of a user of a vehicle. For example, a vehicle may beprogrammed to place an automatic emergency service call (e.g., transmitan electronic report) via a wireless 3G modem incorporated into thevehicle. In case of an accident, the vehicle can place can the automaticemergency service call to inform the authorities about an accident in aninstant and with no regard to the user's condition. For example, suchreport may contain a location of the vehicle determined via on-board GPSreceiver, the user's or owner's personal information such as, but notlimited to, age, sex, residency, phone number and/or the user's medicalcondition. For example, such report may also contain data regarding thevehicle itself such as make, year, VIN (Vehicle Identification Number),license plate, airbag deployment status and/or telemetry data of thelast 2 minutes. For example, the report can include enough informationto determine the time and location of the accident, severity, probablemedical profile of the injured, the vehicle to look for and family tocontact which will allow the emergency response teams to perform theirduties with improved efficiency. Such detailed description of the sceneand those likely involved raise serious privacy concerns.

For example, in case of an accident, the following may occur:

-   -   1. a sensor residing in the “safety network” (which is connected        to the communication lockdown ECU) detects an accident and the        ECU assigned to the task prepares the report for the        authorities. The report is received by the lockdown ECU and        verified according approved message dictionary and communication        schema.    -   2. The ECU establish an internal communication with the        communication lockdown ECU containing (or directly connected to)        the 3G modem via CAN bus interface and transmits the report to        it.    -   3. The communication lockdown ECU establishes a new encrypted        connection to an authenticated remote emergency notification        server and sends the report.

In this scenario, in accordance with some embodiments, the sensitiveinformation travels unencrypted on the on-board networks, but isverified, encrypted and transmitted to the right external destination bythe inventive lockdown devices.

In some embodiments, a physical housing in which the inventive lockdowndevice(s) reside can include temper-proofing measures which can detectthat the physical housing has been opened or breached (e.g., utilizingmicro-switch sensors, optical sensors and other similarly suitabletechniques/devices) and securely erase all software and data stored inthe inventive lockdown device(s).

In some embodiments, the inventive lockdown devices can be configured toauthenticate and/or verify external software packages which need to bedeployed within the vehicle. For example, the inventive lockdown devicescan be configured to verify the cryptographic signature of the externalsoftware packages, unencrypt them and deploy them in the approved ECU(s)only.

In some embodiments, when ECUs are utilizing a session basedcommunication protocol which requires acknowledgments of communicationbeing received, the inventive lockdown devices can be configured toblock the communication and then send a notification to the sending ECUsthat the message was not received.

In some embodiments, the inventive lockdown devices can be deployed toprotect a single communication link (between and single ECU and thenetwork).

In some embodiments, the inventive lockdown device and the inventivestate machine can take into account states of external systems which arecommunicating with the vehicle through an external communicationinterface (e.g. 3G cellular, Wi-Fi, etc.).

Illustrative Examples for Configuration Lockdown of ECUs Based on StaticRuntime Environment Enforcer (SREE)

In some embodiments, to enforce the security configuration lockdown forautomotive ECUs, or any computing system, the exemplary inventivelockdown device(s) can include and/or is/are configured as inventiveSREE component(s) which securely validate(s) all memory access to ensurethat the approved software package(s), approved memory map(s), and/orapproved hardware configuration(s) are not modified during the runtime.

In some embodiments, an exemplary inventive SREE component can beimplemented as a hardware component (whether an application-specificintegrated circuit (ASIC) or a field-programmable gate array (FPGA))which is located immediately before the runtime and storage memory,interconnected directly to the memory components (without any otherdevices being directly connected to them (i.e., being physicallynon-bypassable), and which verifies all memory accesses. In someembodiments, the exemplary inventive SREE component can be implementedas a firmware component to securely enforce the memory lockdown. In someembodiments, the exemplary inventive SREE component can be implementedas the combination of the hardware and the firmware.

In some embodiments, the exemplary inventive SREE component isconfigured to protect the associated computing system(s) from malicioussoftware the runs on top of the operating system, as a separateapplication and/or inject itself as part of another application. In someembodiments, the exemplary inventive SREE component is configured toprotect the associated computing system(s) from the malicious software'sabilities to gain access to secure resources through a process called“privilege escalation”. Typically, the “privilege escalation” requiresattacking the operating system core (or kernel) to gain the same levelof access as the operating system core. In some embodiments, theexemplary inventive SREE component is configured to be part of a layerof BSP (Board Support Package) firmware which resides below theoperating system core software. For example, typically, in embeddedsystems, it is referred to as BSP and in PCs is referred to as BIOS(Basic Input/Output System). As referenced here, the term “BSP” includesany type of middleware which resides between an operating system andhardware (which includes the bootloader). As detailed above, BSP is aset of drivers which provide an interface for the operating system toaccess the hardware components of the computing system. As detailedabove, typically, the BSP can include drivers for processor access(e.g., architecture support package (ASP)), drivers for memory access(the memory management unit, storage memory, and runtime operationalmemory) and/or drivers for peripheral devices (e.g., network card, videocard, USB controller, etc.). As detailed above, for example, within theWind River's BSP for ARM Integrator 920T board, the flashMem.c filecontains device driver for the board's flash memory and romInit.s filecontains ROM initialization module for the board, software images thatstart running from ROM. In some embodiments, the exemplary inventiveSREE component is configured to implement the ECU lockdown principlesdetailed herein independently and agnostically from any operatingsystem.

For example, as illustrated in FIG. 19, the exemplary inventive SREEcomponent is implemented as an integral component of the BSP so that allmemory access operations are routed through the exemplary inventive SREEcomponent. In some embodiments, the exemplary inventive SREE componentis configured to decide whether to allow the execution of the memoryaccess operations or to block them, thus essentially blocking an attack.In some embodiments, the exemplary inventive SREE component isconfigured to make its determination based, at least in part, on one ormore of the following criteria: a type of memory request (e.g., read orwrite), a target memory (e.g., storage or runtime) and/or specificmemory address or a memory address range which is being sought toaccess.

In some embodiments, the exemplary inventive SREE component isconfigured to implement the enforcement of an approved memory map bydenying access (whether write, read or both) to specific predefinedaddress ranges in the memory (both storage and runtime). In such amanner, as FIG. 20 illustrates, the exemplary inventive SREE componentis configured to ensure that the approved memory map isn't beinginvalidated and the protected memory regions aren't being accessed.Table 2 illustrates an exemplary code which can be utilized by theexemplary inventive SREE component to perform in accordance with theexample of FIG. 20.

TABLE 2 BOOL EnforceMemoryMap(MemOp operation, MemType type, Mem_Adaddress) { If(operation = = READ) { | If(IsAddressReadable(type,address) == TRUE) // Check whether the “address” is allowed read accessin memory “type”. | | | | | | | | | | | | // This function contains theaddress access map for each memory | | return TRUE; | else | | returnFALSE; } else // operation == write { | if(IsAddressWritable(type,address) == TRUE) // Check whether the “address” is allowed write accessin memory “type” | | return TRUE; // Return TRUE in case of successfulwrite and FALSE in case of failed write | else | | return FALSE; } }

In some embodiments, the exemplary inventive SREE component isconfigured to implement the enforcement of an exemplary approvedhardware configuration, by, for example, storing a list of memoryaddresses which contain the hardware configuration and allow only readoperations. For example, as shown in FIG. 21, during a system boot (oran initialization procedure), the exemplary inventive SREE component isconfigured to enforce a read-only access to hardware during the bootprocess only and then prevent any access to these memory spaces, makingthis memory segment into Read Only Memory (ROM). In some embodiments,once the approved hardware configuration is retrieved successfully, theexemplary inventive SREE component is configured to allow the operatingsystem or any other software/firmware to configure the hardwarecomponents. Table 3 illustrates an exemplary code which can be utilizedby the exemplary inventive SREE component to perform in accordance withthe example of FIG. 21.

TABLE 3 BOOL EnforceHWCOnfig(MemOp operation, MemType type, Mem_Adaddress) { if (operation != READ) // Only read operations are allowedfor HW config addresses | return FALSE; if (type != STORAGE_MEM) // HWconfig is stored in Storage Memory only | return FALSE; if(IsSystemInBoot( ) != TRUE) // Enforce reading only when system is inboot - optional | return FALSE; | if(IsAddressHWConfig(address) ==FALSE) | Return TRUE; | if (IsAddressReadable(type, address) == TRUE) |Return TRUE; else | return FALSE; }

In some embodiments, the exemplary inventive SREE component isconfigured to implement the enforcement of an exemplary approvedsoftware package hardware configuration, by utilizing at least twomechanisms, one for storage memory and the other for runtime memory asshown in FIG. 22. In some embodiments, to prevent modification of theapproved software package stored in the storage memory, the exemplaryinventive SREE component is configured to utilize a list of addressspaces where the approved software package is stored and prevent anymodification to it (e.g., all write access will be prevented). In someembodiments, an operating system is programmed to load software onlyfrom these secure address spaces, moreover the exemplary inventive SREEcomponent can be stored in these secure address spaces as well. Forexample, these secure address spaces are included in the approved memorymap and enforced, by the exemplary inventive SREE component through it.

In some embodiments, the exemplary inventive SREE component isconfigured to prevent a modification in the runtime memory, by employinga two-part approach. The first part of the runtime memory shall haveread permissions only and contain the executable code of the approvedsoftware packages during the runtime. For example, the exemplaryinventive SREE component enforces the loading of such code according tothe approved software package specification during the boot process andwithout the intervention of the operating system. The operating systemis able to read it from the runtime memory in order to execute thesoftware. The operating system must contain a static configuration ofaddress spaces of all approved software code in order to execute it. Alldata which is used by software during the runtime shall be stored in anon-protected section of the runtime memory (the second part) and ismade fully available to the operating system. Such separation shall befully static and configured in advance as part of the approved memorymap. For example, the memory sections reserved for the exemplaryinventive SREE component shall be denied access according to theapproved memory map. Table 4 illustrates an exemplary code which can beutilized by the exemplary inventive SREE component to perform inaccordance with the example of FIG. 22.

TABLE 4 BOOL LoadSoftwarePackage( ) // Load software package fromstorage memory to runtime memory during boot { if (IsSystemInBoot( ) !=TRUE) | return FALSE; | image =ReadSoftwarePackgeImageFromStorageMem(START_ADDRESS, END_ADDRESS); //Loads software image from storage if (image == FALSE) | return FALSE; |return WriteSiftwarePackgeImageToRuntimeMem(image); //Writes the imageto runtime memory and return TRUE if succeeded } BOOLEnforceSoftwarePackage(MemOp operation, MemType type, Mem_Ad address) {if (type == STORAGE) | return TRUE; | return EnforceMemoryMap(oepration,RUNTIME, address); // The memory map contains all memory segments whichare denied | | | | | | | | | | | | | // access and contain the softwarepackage }

In order to store the approved memory map, approved hardwareconfiguration and approved software list, the exemplary inventive SREEcomponent is configured to use a dedicated part of the storage memorywhich will be mapped as inaccessible and used by the exemplary inventiveSREE component only as shown in FIG. 23.

In some embodiments, the exemplary inventive SREE component isconfigured to use a dedicated hardware storage memory which theoperating system is not aware of (the address spaces of the dedicatedhardware storage memory are not known or reflected by the memorycontroller to the OS) and only the exemplary inventive SREE component isconfigured to access the dedicated hardware storage memory.

In some embodiments, for example, when a memory access command isissued, the exemplary inventive SREE component is configured to verifywhether to execute the memory access command or not according to atleast one of the type of operation, memory being accessed and/orspecific memory address (and/or range of addresses) being accessed; andby checking at least one of whether the memory access commandinvalidates the approved software package, whether the memory accesscommand invalidates the approved memory map and whether the memoryaccess command invalidates the approved hardware configuration (or anysubset of thereof). In some embodiments, the exemplary inventive SREEcomponent is configured to perform the validation in any order. In case,the exemplary inventive SREE component invalidates the memory accesscommand, the exemplary inventive SREE component blocks (not permittingto be executed) the memory access command and an attack are prevented.If the exemplary inventive SREE component approves the memory accesscommand, the operation shall be executed by the exemplary inventive SREEcomponent or being passed for execution by the exemplary inventive SREEcomponent to another component (e.g., micro-processor) and any result(e.g. the result of the memory read operation) returned by the exemplaryinventive SREE component or by another component, as shown in FIG. 24.Table 5 illustrates an exemplary code which can be utilized by theexemplary inventive SREE component to perform in accordance with theexample of FIG. 24.

TABLE 5 MemVal ExecuteMemoryOperation(MemOp operation, MemType type,Mem_Ad address, MemVal value) { if (EnforceHWCOnfig(operation, type,address) != TRUE) | return FALSE; | if (EnforceMemoryMap(operation,type, address) != TRUE) | return FALSE; | if(EnforceSoftwarePackage(operation, type, address) != TRUE) | returnFALSE; | if (operation == READ) | return ReadMemory(type, address); //Reads memory and return value else // write operation | returnWriteMemory(type, address, value); // Writes “value” into memory andreturn TRUE of succeeded }

For example, FIG. 25 illustrates an exemplary approved memory map forstorage and runtime memory (addresses are in bytes). During the bootprocess the software package (or software image) is coped from thestorage memory to the runtime memory so it can run. During boot thehardware configuration is accessed to configure the hardware andafterwards access will be prevented. After the boot process has finished(the boot process lasts between the time the ECU is turned on until theoperating system is fully loaded and running), all memory accessattempts shall go through the validation schema enforced by theexemplary inventive SREE component as, for example, shown in FIG. 24.For instance, a storage memory access to write into address 128 isdenied, however reading from address 228 is executed. Write attempt toruntime memory address 56 is denied while read attempt is allowed.Addresses 0-99 in the storage memory shall be used by the exemplaryinventive SREE component only to read the configuration of the approvedmemory map and/or approved software packages. Table 6 illustrates anexemplary code which can be utilized by the exemplary inventive SREEcomponent to perform in accordance with the example of FIG. 25.

TABLE 6 BOOL IsAddressReadable(MemType type, Mem_Ad address) { if (type== STORAGE) | if (address > 99) | | return TRUE; | | if (type ==RUNTIME) | return TRUE; | Return FALSE; } BOOL IsAddressWritable(MemTypetype, Mem_Ad address) { if (type == STORAGE) | if (address > 149) | |return TRUE; | | if (type == RUNTIME) | if (address > 99) | | returnTRUE; | | Return FALSE; } BOOL IsAddressHWConfig(MemType type, Mem_Adaddress) { if (type == RUNTIME) | return FALSE; | if (address < 150 &&address > 99) | return TRUE; | return FALSE; }

In some embodiments, the exemplary inventive SREE component isconfigured to enforce the configuration lockdown by utilizing anycombination of the above enforcement components (e.g., the approvedmemory map, the approved software packages and the approved hardwareconfiguration). In some embodiments, the exemplary inventive SREEcomponent is configured to perform verification in any order between theabove enforcement components. For example, the exemplary inventive SREEcomponent is configured to join together the above enforcementcomponents into a single verification condition (instead of breakingthem up into three). For example, in some embodiments, the approvedmemory map and approved hardware configuration can also be loaded intothe runtime memory during boot and reside within the protected memoryspace there.

For example, by preventing all access to the storage memory whichcontains all configuration and executable software code, the exemplaryinventive SREE component is configured to provide protection in casemalicious software manages to gain access to the ECU. Even if malicioussoftware manages to run itself on parts of the runtime memory, which areunprotected, the malicious software is not be able to store itself inmemory and load the next time the ECU is turned on. Thus, the exemplaryinventive SREE component is configured to ensure that, for example, oncethe ECU is turned off and is back on, only the approved software loadsand runs. The exemplary inventive SREE component is configured to ensurethat, for example, once the ECU is turned down, it will revert to thepredefined static configuration which doesn't include the maliciouscode.

In some embodiments, beyond enforcing the approved software packageand/or the other above enforcement components, the exemplary inventiveSREE component is configured to be transparent to the operating system(OS) and any application running on top of the OS. For example, if anapplication tries to access the protected memory as if the protectedmemory is not there, the application may receive an access error whichthe exemplary inventive SREE component can return but withoutnecessarily alerting the application the actual cause for the error. Forexample, only in the case of the approved software package enforcementin the runtime memory (for example, if only the enforcement of thestorage memory is used, then the exemplary inventive SREE component isalso transparent), the OS must be aware of the exemplary inventive SREEcomponent as described above.

In some embodiments, the exemplary inventive SREE component isconfigured as a static component with the static operation logic. Forexample, the exemplary inventive SREE component is configured to beindependent from the Operating System (which only needs to know themapping it enforces, thus being dependent on the exemplary inventiveSREE component, but not the other way around) and from the way theOperating System runs an application. In some embodiments, the exemplaryinventive SREE component is configured to only enforce the lockdownconfiguration by validating the memory access.

In some embodiments, the exemplary inventive SREE component isconfigured to also serve as firmware memory management unit (MMU) whichreduces the need for a hardware management unit and allows theenforcement to be completely transparent to the OS. The OS relies on thememory management unit to provide the total address space of the memorywhich is accessible to the OS. Thus, if the exemplary inventive SREEcomponent is also the MMU, the exemplary inventive SREE component onlydeclares to the OS the address ranges which are not locked down. Inaddition, the exemplary inventive SREE component is configured tovirtualize memory allocation of the OS so that once the OS decides toload the approved software into the runtime memory, the exemplaryinventive SREE component is configured to verify that it is indeed inthe approved software, by loading the software, separating its code anddata memory while relaying to the OS that they are not separated. Thus,the exemplary inventive SREE component is configured to virtuallytranslate the address where the OS would like the code to be into theactual protected address where the code resides.

In some embodiments, the exemplary inventive SREE component isconfigured to include at least one micro-processor and/or FPGA which isconnected between the memory and the rest of the ECU components asdescribed in FIG. 26. For example, in some embodiments, the inventiveFPGA is implemented having the same logic as described above (FIG.21-24) and maintain the approved software configuration, approved memorymap and approved hardware configuration. In some embodiments, theenforcement configurations is stored in the storage memory and protectedby the inventive FPGA. In some embodiments, the inventive FPGA isconfigured to decide whether to allow or deny memory operations duringruntime while maintaining required memory segmentation (e.g., no access,read-only, etc.) and executing preliminary tasks of loading code fromstorage memory into runtime memory as described in FIG. 22.

In some embodiments, the exemplary inventive SREE component isconfigured to provide the memory access enforcement utilizing ahypervisor to provide a firmware layer which may supervise access inbetween the OS and the hardware and decide whether to allow or denymemory operations during the runtime while (1) maintaining the requiredmemory segmentation (e.g., no access, read-only, etc.) and (2) executingpreliminary tasks of loading code from storage memory to runtime memory.In some embodiments, the exemplary inventive SREE component providing ahypervisor may be configured to virtualize a memory allocation of the OSso that once the OS decides to load the approved software into theruntime memory, the exemplary inventive SREE component is configured toverify that it is indeed in the approved software, by loading thesoftware and separating its code and data memory while relaying to theOS that they are not separated. Thus, the exemplary inventive SREEcomponent may be configured to virtually translate the address where theOS would like the code to be into an actual protected address where thecode would reside.

Illustrative examples for secure physical separation of communicationnetworks in ECU(s)

In some embodiments, to enforce the security communication lockdown, theinventive lockdown device(s) is/are configured to enforce the separationbetween different interconnected networks which are connected to theinventive lockdown device(s). For example, as detailed above, theinventive lockdown device(s) can be configured to enforce the softwarelevel separation through the inventive separation kernel(s) enforcingthat each communication interface resides in its own partition.

In some embodiments, to enforce the security communication lockdown incase of, for example, Denial of Service (DoS) attacks, the inventivelockdown device(s) can be further configured to enforce the hardwareseparation before an attacker is able to enter the system/device.

In some embodiments, to enforce the hardware separation, the exemplaryinventive device(s) (e.g., the inventively modified ECUs) is/areconfigured to utilize, for example but not limited to, a specificallyprogrammed Field Programmable Gate Array (FPGA) chip, a complexprogrammable logic device (CPLD) and/or another similarly suitableprogrammable hardware processor. Specifically, the inventive modifiedFPGA contains a matrix of basic logic cells which can be interconnectedin any way to enforce a static configuration which cannot be changedduring runtime. For example, in some embodiments, the inventive modifiedFPGA can be configured to have separate hardware transceivers for eachinterface. For example, a transceiver for a specific interfaceimplements the electrical and electronic communication protocol requiredto send and receive data over a specific interface (e.g. Ethernet, CAN,MOST, etc.). Having a separate set of transceivers for each specificinterface allows the inventive modified FPGA to communicate with all ofthe different hardware interfaces which connect to the inventivecommunication lockdown device(s). For example, in some embodiments, thetransceivers can be either external dedicated hardware or internal tothe FPGA in form of on chip hardware and/or semiconductor intellectualproperty (IP) core(s) (each which is a reusable unit of logic, cell, orchip layout design implementation of a particular functionality on FPGA;to program an FPGA, one can use IP core(s) which define hardwarecomponents inside it).

For example, the present invention can utilize a dedicated transceiverwhich is suitably similar to Texas Instruments Inc.'s TCAN334G™ chip.For example, the present invention can configure hardware which issuitably similar to an illustrative System on Chip with built-in FPGAand CAN transceivers of Xilinx, Inc.'s Zynq7000™. For example, thepresent invention can utilize Xilinx, Inc.'s CAN IP core which can beimplemented in the FPGA to allow for communications.

As used herein, the term “transceiver” is directed to a combination ofhardware and software that typically translates analog signals going onbuses into digital bits. For example, some transceivers can alsoassemble the bits into a packet. For example, each IP core in accordancewith the present invention receives individual bits from respectivetransceiver(s) and assembles them into packet(s) and/or message(s)according to a particular communication protocol. In some embodiments,with the built-in transceivers, usually both functions (i.e., thetranslation and the assembly) can be included. In some embodiments, withthe external transceivers, the inventive modified FPGA can be configuredto include each respective IP core. For example, FIG. 29 illustratesexemplary external transceivers.

In turn, in some embodiments, the inventive modified FPGA cancommunicate with the processor running the above detailed inventivecommunication lockdown system firmware and software as shown in FIG. 27.FIG. 10 shows an enlarged view of a component which includes an itemdesignated as “security core” in FIG. 27. In some embodiments, thesecurity core can include the inventive state machine and/or theapproved message dictionary database, and/or the approved communicationschema database.

For example, to enforce the security communication lockdown, theinventive lockdown device(s) can include the inventive modified hardwarecomponent (e.g., inventive modified FPGA) or components, at least oneper each interface, which verify the communication integrity and rateaccording to the approved message dictionary and/or the approvedcommunication schema; and communicate with all of the required networks(interfaces) accordingly. In some embodiments, the inventive modifiedhardware component within the inventive modified FPGA is staticallyconstructed to verify communications against the approved messagedictionary and/or the approved communication schema on, for example, thebit level. In some embodiments, to enforce the security communicationlockdown, the inventive modified hardware component can be configured toperform a full verification of all communication and message bits, or apartial by only verifying a source and/or a destination of a messageagainst the approved message dictionary database and/or the approvedcommunication schema database. In some embodiments, the approved messagedictionary database and/or the approved communication schema databasecan be statically stored in hardware as part of the inventive modifiedFPGA

In some embodiments, to enforce the security communication lockdown, theapproved message dictionary is programmed as part of the inventivemodified FPGA configuration (e.g., a part of a network message verifiercomponent) making, the inventive modified FPGA completely static inruntime. In some embodiments, to enforce the security communicationlockdown, the inventive modified FPGA is configured to verify, forexample, the approved rate of messages on a specific interface, aspecific type of messages, etc. Any message which will not pass theverification is dropped (blocked) and thus the inventive modified FPGAis configured to block the attack.

In some embodiments, all network interfaces communicate with the hostCPU via a unified communication interface (e.g., Ethernet) which canalso translate the communication into a unified protocol and back (e.g.,TCP/IP). FIG. 28 shows an example of the inventive hardware networkseparation based on the inventive modified FPGA. For example, theinventive hardware network separation based on the inventive modifiedFPGA can allow for at least one of the following:

-   -   increasing in a speed of execution since the inventive modified        FPGA serves as the dedicated hardware component used only for        specific purpose,    -   being physically separate from all other interfaces and the        system software,    -   offloading some of the processing from the software component on        the CPU which needs to do more complex analysis (e.g., in case        of a DoS attack, the attacking message(s) is/are stopped in the        inventive hardware before they reach the software component,        thus preventing the communication overflow from advancing),    -   implementing basic checks against the approved message        dictionary on a faster rate and may reduce a load on the        inventive secure separation kernel, and    -   being resilient to various forms of attacks such as, but not        limited to, buffer overflows and code injection.

Of note, the embodiments described herein may, of course, be implementedusing any appropriate hardware and/or computing software languages. Inthis regard, those of ordinary skill in the art are well versed in thetype of computer hardware that may be used, the type of computerprogramming techniques that may be used (e.g., object orientedprogramming), and the type of computer programming languages that may beused (e.g., C++, Basic, AJAX, Javascript). The aforementioned examplesare, of course, illustrative and not restrictive.

While a number of embodiments of the present invention have beendescribed, it is understood that these embodiments are illustrativeonly, and not restrictive, and that many modifications may becomeapparent to those of ordinary skill in the art, including that theinventive methodologies, the inventive systems, and the inventivedevices described herein can be utilized in any combination with eachother. Further still, the various steps may be carried out in anydesired order (and any desired steps may be added and/or any desiredsteps may be eliminated).

What is claimed is:
 1. A system, comprising: at least one securecommunication lockdown device that is located within a vehicle andcomprises: at least one respective processor that is at least programmedto: receive each respective electronic message; verify at least oneportion of each respective electronic message against: i) at least oneportion of at least one pre-defined approved message dictionary or ii)at least one portion of at least one finite state machine; determine,based on the verification of the at least one portion of each respectiveelectronic message, that each respective electronic message is: i) anunauthorized electronic message or ii) an approved electronic message;generate at least one respective indication for the at least onerespective electronic message, wherein the at least one indication isconfigured to identify the at least one respective electronic message asbeing the approved electronic message or the unauthorized electronicmessage; and wherein the at least one other communication lockdowndevice is dedicated to at least one of: i) at least one physicallyseparate communication network, ii) at least one physically separateexternal communication entry-exit point, or iii) at least one physicallyseparate ECU.
 2. A method, comprising: installing at least one securecommunication lockdown device that is located within a vehicle andcomprises: at least one respective processor that is at least programmedto: receive each respective electronic message; verify at least oneportion of each respective electronic message against: i) at least oneportion of at least one pre-defined approved message dictionary or ii)at least one portion of at least one finite state machine; determine,based on the verification of the at least one portion of each respectiveelectronic message, that each respective electronic message is: i) anunauthorized electronic message or ii) an approved electronic message;generate at least one respective indication for the at least onerespective electronic message, wherein the at least one indication isconfigured to identify the at least one respective electronic message asbeing the approved electronic message or the unauthorized electronicmessage; and wherein the at least one other communication lockdowndevice is dedicated to at least one of: i) at least one physicallyseparate communication network, ii) at least one physically separateexternal communication entry-exit point, or iii) at least one physicallyseparate ECU.